In a data processing system, a backup/restore subsystem is typically used to save a recent copy or version of one or more data sets, or a portion thereof, on some form of backup data storage device, such as magnetic or optical disk drives, tape drives, or other memory. The backup/restore subsystem is used to protect against loss of data. For example, if an on-line version of one or more data sets is destroyed, corrupted, deleted, or changed because of power failure, hardware, or software error, user error or some other type of problem, the latest version of those data sets which are stored in a backup/restore subsystem can be restored and therefore the risk of loss of data is minimized.
As but one example, a log-structured array subsystem (LSA) implements “virtual volumes”, wherein each virtual volume is created using a “virtual track table” having pointers to “virtual tracks” (i.e., records) in a sequential byte stream, wherein updated tracks are written to a new location at the logical end of the byte stream, and their associated pointers are reset to the new locations. Thereafter, the tracks at the old location in the sequential byte stream are no longer needed and can be released as free space for reclamation and reuse. The storage can take place in standard direct access storage device (DASD) with sequentially numbered tracks buy the use of an emulation system.
Currently available LSA subsystems generally support a fast copy function that can be referred to herein as FlashCopy®. The fast copy function operates by copying pointers between virtual track tables representing different virtual data volumes, without actually moving any data. Reference in this regard can be made, as an example, to commonly assigned U.S. Pat. No. 6,212,531 B1, “Method for Implementing Point-In-Time Copy Using a Snapshot Function”, to Blea et al. Reference with regard to fast copy operations may also be had to the following commonly assigned U.S. Pat. Nos. 6,078,932, “Point-In-Time Backup Utilizing Multiple Copy Technologies”, Haye et al.; 6,131,148,“Snapshot Copy of a Secondary Volume of a PPRC Pair”, West et al.; 6,182,198 B1, “Method and Apparatus for Providing a Disc Drive Snapshot Backup Capability While Allowing Normal Drive Read, Write, and Buffering Operations”, Hubis et al.; and 6,393,537 B1, “Host Storage Management Control of Outboard Data Movement”, Kern et al.
Reference can also be made to U.S. Pat. No. 5,915,264, “System for Providing Write Notification During Data Set Copy”, White et al., that describes a write notification during copy system that functions to enable a data processor to manage the data file copy function of a disk data storage subsystem in a manner that is said to minimize the expenditure of data processor resources. This is accomplished by the write notification, during copy, system determining the source volume on the data storage subsystem, the target volume on the data storage subsystem and identifying the extents of both. The write notification during copy system then transmits data to the data storage subsystem, representative of the assignment of DASD full tracks from the source location on the data storage subsystem, as well as DASD full tracks from the target location on the data storage subsystem. The system then uses Extended Control and Monitoring (ECAM) channel programs to instruct the data storage subsystem to perform the data file copy operation using fast copy track pointer copy operations. Upon conclusion of the data file copy operation by the data storage subsystem, the write notification during copy system updates the meta data required to complete the data file copy operation and indicates whether the copy completed with or without any conflicting write operation against the source or target.
A problem exists in current storage systems that provide the capability to provide a fast copy of data within the storage system. The problem is related to the fact that the system does not select the target storage volume for the copy, but instead requires that the user manually select the target volume. As may be appreciated, this can be an error-prone procedure, as the user may inadvertently select volumes that are in use by other systems, resulting in a possible loss of data. Furthermore, unless the user has an appreciation and knowledge of the internal architecture of the data storage system, the user will not normally select a target volume that is optimal with respect to at least one of performance, availability and reliability. As but one example, if the user should select as a target volume one having one or more tracks located on the same physical disk as the source data, then a double disk failure could result in a loss of both the source volume and the target volume. The problem of manual selection of the target volume for a fast copy operation is compounded for those systems having large, virtualized data storage facilities (e.g., tens to thousands of potential target volumes located on hundreds or thousands of physical disks), as well as in those systems that provide heterogenous and dynamic environments.